Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustc: factor out most of hir::def::Def's variants into DefKind, and rename to Res. #60462

Merged
merged 3 commits into from
May 4, 2019

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented May 1, 2019

The first two commits are about introducing DefKind, both to simplify/orthogonalize hir::def::Def, and to allow reasoning about the kind of a definition without dealing with the redundant DefId.
(There are likely more changes to be made, such as adding enough DefKind variants for tcx.def_kind(def_id) to return just DefKind, not Option<DefKind>, but this is pretty big as-is)

The third commit frees up the Def name (which we may want to use in the future for "definitions", in the sense of "entities with a DefId") by renaming hir::def::Def to Res ("resolution").
IMO this fits, as it represents all the possible name resolution results, not just "definitions (with a DefId)".

Quick examples:

// Before:
if tcx.describe_def(def_id) == Some(Def::Struct(def_id)) {...}
if let Def::Struct(def_id) = path.def {...}
// After:
if tcx.def_kind(def_id) == Some(DefKind::Struct) {...}
if let Res::Def(DefKind::Struct, def_id) = path.res {...}

r? @petrochenkov cc @rust-lang/compiler

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 1, 2019
src/librustc/hir/def.rs Show resolved Hide resolved
src/librustc/hir/mod.rs Show resolved Hide resolved
@bors
Copy link
Contributor

bors commented May 2, 2019

☔ The latest upstream changes (presumably #60460) made this pull request unmergeable. Please resolve the merge conflicts.

@@ -1104,7 +1124,7 @@ impl ModuleOrUniformRoot<'_> {
fn same_def(lhs: Self, rhs: Self) -> bool {
match (lhs, rhs) {
(ModuleOrUniformRoot::Module(lhs),
ModuleOrUniformRoot::Module(rhs)) => lhs.def() == rhs.def(),
ModuleOrUniformRoot::Module(rhs)) => lhs.def_id() == rhs.def_id(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just to confirm, this change is ok, because the DefKind would be the same if the DefId is the same?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, DefKinds must be the same for same DefIds.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Especially since this is a Module, so a mod/enum/trait, which don't even have the potential ambiguity that constructors can.

Node::Ctor(variant_data) => {
// FIXME(eddyb) is this even possible, if we have a `Node::Ctor`?
if variant_data.ctor_hir_id().is_none() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Insert an assert to find out?

@@ -310,14 +310,14 @@ impl<'hir> Map<'hir> {
self.definitions.as_local_node_id(def_id.to_def_id()).unwrap()
}

pub fn describe_def(&self, node_id: NodeId) -> Option<Def> {
fn def_kind(&self, node_id: NodeId) -> Option<DefKind> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was surprised that this worked and users of describe_def never needed the DefId-less variants, but if it's called only from a DefId-based query, then it's understandable.

@petrochenkov
Copy link
Contributor

r=me after rebase
@bors p=1

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 2, 2019
@eddyb eddyb force-pushed the def-1-a-mere-resolution branch from c4c23c9 to 393c8bc Compare May 3, 2019 16:02
@eddyb
Copy link
Member Author

eddyb commented May 3, 2019

@bors r=petrochenkov

@bors
Copy link
Contributor

bors commented May 3, 2019

📌 Commit 393c8bc24885671ebde87a74ca8d651a79f9bd23 has been approved by petrochenkov

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 3, 2019
@bors
Copy link
Contributor

bors commented May 3, 2019

☔ The latest upstream changes (presumably #60510) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 3, 2019
@eddyb eddyb force-pushed the def-1-a-mere-resolution branch from 393c8bc to ff174fe Compare May 3, 2019 19:50
@eddyb
Copy link
Member Author

eddyb commented May 3, 2019

@bors r=petrochenkov

@bors
Copy link
Contributor

bors commented May 3, 2019

📌 Commit ff174fe has been approved by petrochenkov

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 3, 2019
@eddyb
Copy link
Member Author

eddyb commented May 3, 2019

@bors p=100 (this bitrots almost instantly, should be merged before the next rollup)

@bors
Copy link
Contributor

bors commented May 3, 2019

⌛ Testing commit ff174fe with merge 13fde05...

bors added a commit that referenced this pull request May 3, 2019
rustc: factor out most of hir::def::Def's variants into DefKind, and rename to Res.

The first two commits are about introducing `DefKind`, both to simplify/orthogonalize `hir::def::Def`, and to allow reasoning about the kind of a definition without dealing with the redundant `DefId`.
(There are likely more changes to be made, such as adding enough `DefKind` variants for `tcx.def_kind(def_id)` to return just `DefKind`, not `Option<DefKind>`, but this is pretty big as-is)

The third commit frees up the `Def` name (which we may want to use in the future for "definitions", in the sense of "entities with a `DefId`") by renaming `hir::def::Def` to `Res` ("resolution").
IMO this fits, as it represents all the possible name resolution results, not just "definitions (with a `DefId`)".

Quick examples:
```rust
// Before:
if tcx.describe_def(def_id) == Some(Def::Struct(def_id)) {...}
if let Def::Struct(def_id) = path.def {...}
```
```rust
// After:
if tcx.def_kind(def_id) == Some(DefKind::Struct) {...}
if let Res::Def(DefKind::Struct, def_id) = path.res {...}
```

r? @petrochenkov cc @rust-lang/compiler
matthiaskrgr added a commit to matthiaskrgr/rust-clippy that referenced this pull request May 4, 2019
@bors
Copy link
Contributor

bors commented May 4, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: petrochenkov
Pushing 13fde05 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 4, 2019
@bors bors merged commit ff174fe into rust-lang:master May 4, 2019
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #60462!

Tested on commit 13fde05.
Direct link to PR: #60462

💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk @phansch, @rust-lang/infra).
💔 clippy-driver on linux: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk @phansch, @rust-lang/infra).
💔 miri on windows: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 rls on windows: test-fail → build-fail (cc @Xanewok, @rust-lang/infra).
💔 rls on linux: test-fail → build-fail (cc @Xanewok, @rust-lang/infra).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request May 4, 2019
Tested on commit rust-lang/rust@13fde05.
Direct link to PR: <rust-lang/rust#60462>

💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk @phansch, @rust-lang/infra).
💔 clippy-driver on linux: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk @phansch, @rust-lang/infra).
💔 miri on windows: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 rls on windows: test-fail → build-fail (cc @Xanewok, @rust-lang/infra).
💔 rls on linux: test-fail → build-fail (cc @Xanewok, @rust-lang/infra).
@eddyb eddyb deleted the def-1-a-mere-resolution branch May 4, 2019 02:09
bors added a commit to rust-lang/rust-clippy that referenced this pull request May 4, 2019
Rustup to rustc 1.36.0-nightly (13fde05 2019-05-03)

Trying to deal with changes from rust-lang/rust#60462

Moved from #4060 so everyone can collab on the rustup branch.
bors added a commit that referenced this pull request May 5, 2019
rustc: collapse relevant DefPathData variants into {Type,Value,Macro,Lifetime}Ns.

`DefPathData` was meant to disambiguate within each namespace, but over the years, that purpose was overlooked, and it started to serve a double-role as a sort of `DefKind` (which #60462 properly adds).
Now, we can go back to *only* categorizing namespaces (at least for the variants with names in them).

r? @petrochenkov or @nikomatsakis cc @michaelwoerister
bors added a commit that referenced this pull request May 5, 2019
Rename `PathResolution` to `PartialRes`

Don't use `PartialRes` when `Res` is enough.
Rename `Res::kind_name` to `Res::descr` for consistency.
Remove `Res::Label`, paths can never resolve to labels.

Some further cleanup after #60462
r? @eddyb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants